Radial Anisotropy position issue

#1

I’ve got a bunch of parts coming from Rhino, which is Z up of course. Super odd, but my initial file of just some of the individual parts worked fine. I couldn’t figure out, for the Life of me, why my radial brush material was flipping out. And when I imported in just the part that worked, it was fine, until I tried to reposition the radial texture on it.
I Really wish it showed you the texture position. I might have noticed the rotation difference.

I still have major problems though, because Most designers don’t use blocks in Rhino. That means I’ve got 4 objects that are the same geometry, but all have keyshot origins of zero, which is several hundred mm away. Is there a way to reset the origin right in keyshot when you’re in a hurry? I’m going to back and will define a block, then duplicate it into positions so the radial position will be the same.

It would be nice to have control of the origin position of individual objects. I went back into Rhino. Defined one of them as a block, then duplicated them into position. As far as I know, that’s the only way to get the origins to be centered on the part from Rhino to Keyshot. Is there another way?

The other option to fix this would be to duplicate the material for each object and position the radial brush for each object, but it’s a multimaterial, and doing that would make setting up studios for rendering everything a nightmare. It also means the “center” would be eyeballed for each of 4 objects. Not having concentric circles is usually an issue.

#2

The anisotropic material (type) with radial roughness rotates along the Y axis. The position can be changed.

image
image.jpg1531×1027 202 KB

1 Like
#3

I would say the issue with the origins is on how you create your models in Rhino. I just don’t use Rhino but if I model something in MODO for example I can model it anywhere but the smartest thing is to model an object at the actual origin and move the object after it’s been modelled. And in MODO (maybe also Rhino) it makes a difference if I select all polygons and move them to a new position (which keeps the origin at 0,0,0) or be in object mode and move the object, that will move it together with it’s origin so the center of the object won’t be changed.

Took me some time before I saw that logic and maybe old news for you. Don’t really know how Rhino does it and maybe Rhino also has an option to edit an objects origin afterwards. Normally I would say that KS just keeps the origins where they are inside the imported model.

#4

Yes, I’m aware the position can be changed. I’m not sure why, when you manually position it to a face they didn’t make the decision to automatically rotate the gizmo to the face selected, because the default for rhino had Y facing up for my objects. Now that I understand the axis that helps.

And yes, the ideal situation would be that I have an origin for each part in Rhino. But Rhino has No origin information, regardless of where you create it, unless you define it as a block instance. This slows several things down significantly in rhino, like trying to identify bad surfaces when you have 1200 parts, 800 of them being unique. Rhino also handles layers in a wierd way. The actual surfaces can be on a layer, but the block instance itself can be on an entirely different layer. Industrial designers absolutely hate it. I’m not a huge fan either, but I know the tools quite well for cleaning up models and helping eliminate pieces from giant assemblies that aren’t going to be seen in a render.

The favorite by most designers I know is to organize materials by layers, and import the rhino file to keyshot, with no block instances. The problem with this is Keyshot automatically puts the origin at zero, as if the object was created in MODO in place (Which is fine, but you have to position the pivot at some point, usually by centering it, and aligning orientation if needed).
It would be really nice, in keyshot, to be able to move it. AND it would be very helpful to see the values for the radial position so you can just type them in if it needs to be rotated 90, or if you see the position is something like 0,1.5,0 or something like that, you know you can use the same value for matching parts if they aren’t instanced in keyshot.

#5

There are multiple requests about having a nice tool to align certain objects which is currently really time consuming, so I hope that gets reality once. A nice ‘center pivot to object’ or something like that wouldn’t be a bad thing I would say.

But I wonder if there are no scripts or so which you could use with Rhino to get the centers where you want them. Or maybe export to for example FBX and just load it into a modeller where you can adjust the origins. Far from ideal of course but sometimes using some other program can win you a lot of time later on.

#6

Well it gets worse still. I noticed that because of the way the file tree is handled either in Keyshot, or between Rhino and Keyshot, the origins still end up getting offset by whatever the parent is.
I ended up just bouncing the data through blender, but that Also wasn’t without issues.
Even though I was manually editing the origin to make sure Y was facing from the center of the parts I wanted to have the material with radial anisotropy, it was still getting some odd orientations. In that case, when I hit Ctrl+D and chose origin it was correct, but the radial position tool was not and seemed to reflect the orientation of the parent, which in that case is an empty layer that is probably linked to blender’s world.
So I aligned my object to Y in blender, rotated my camera 90deg and the environment and lights 90deg.

It would be Really nice to be able to fix the orientation of a part if you happen across something that is already in keyshot and ends up a bit funky. The same with orientation and positioning. This would help with using one material for multiple parts as well. Have graphics on one? No problem, just offset that part’s origin before adding the texture that defines the label enough that it would be entirely off of any other part!

I’ll do some more testing later on, but for now it seems like the only Really safe way is to define the part at 0,0,0 making sure the radial is facing Y. Then move it to where it needs to go. I’m not sure I’ll often have multiple parts with the same radial anisotropic material facing different directions, but I’m sure the use case is out there.